A Timed Veri cation of the IEEE 1394 Leader Election Protocol

detailed A B = `A implements B' 1 = root election 2 = cycle detection 3 = root contention solution [7] [27] this paper [4] [26] 1+2 TIP1 TIP2 TIP3 TIP4 3 I3 I2 I1 Impl Spec SPEC TIP Spec ImpA ImpB 1 1+3 which part of the protocol: Figure 5: An overview of research on the IEEE 1394 tree identify phase actually terminates within bounded time, since for the veri cation it is enough to show that it can terminate. Gri oen and Vaandrager [7] have shown that the election in the tree identify phase works correct, under the assumption that the network topology is xed throughout the protocol, that a root contention situation is solved in one atomic step, and that no device tries to become root by having the corresponding force root ag set to true. The models are at a high level of abstraction: there is no timing and communication is modelled with nite queues. The models are I/O automata [16, 17] presented in the IOA language [5]. The paper introduces a new simulation proof technique, called normed simulations. The proofs use invariants and the proposed simulation technique. The proofs have been checked with the theorem prover PVS [22]. Note that cycle detection is done with a predicate that takes the structure of the whole network into account, and does not use timing information, as in IEEE 1394. The predicate used implies that nodes that are part of a cycle will detect this with an error message. In IEEE 1394 (and in the models presented in this paper), the error situation is also detected by nodes that are not part of a cycle themselves, but wedged in between of two cycles. Stoelinga and Vaandrager [27] have shown that the root contention solving protocol in the tree identify phase works correct under the assumption that the network topology is xed throughout the protocol. The models are at an intermediate level of abstraction: on the one hand timers and probabilities are used, but on the other hand communication is modelled with nite queues. The models are probabilistic timed I/O automata [24, 25] presented in the IOA language [5]. The paper introduces two simulation proof techniques, which are special cases of the simulation techniques in [24, 25]. The proofs use invariants and the proposed simulation techniques. The model of the protocol that is presented in [4] is essentially the same as one of the I/O 5 automata examples in the book Distributed Algorithms by Lynch [15]. A correctness proof of this protocol is not given in [15]. The models that either include cycle detection or the root contention protocol are can be considered re nements of the protocol in [15]. 2.3 This veri cation As can be seen in Figure 5, this paper aims to give an implementation relation between the most detailed model from [7] and a more detailed model. In this way, our veri cation adds to a layered veri cation of IEEE 1394 in which models are re ned, that is, more and more detail is added in each step. In order to keep our proof obligations manageable, we do not add too much detail, and hence our model has an intermediate degree of detail with respect to IEEE 1394. The veri cation is carried out by establishing trace inclusion between timed I/O automata through a re nement [16, 17, 19]. The I/O automata are presented in the IOA language [5]. The most detailed model of [7] is an untimed model. This means that the cycle detection is done with a predicate that takes the structure of the whole network into account. In this veri cation, we want to establish that cycle detection based on the timing in IEEE 1394 works correct. In order to do this, we add timers to the model which expire when the leader election takes too much time. We also add timing information to the messages sent, in order to model the delay in communication in IEEE 1394. As argued above, this paper uses a di erent predicate for cycle detection than the one used in [7], in order to conform to the error behaviour of IEEE 1394. As in [7] we assume that the network topology is xed throughout the protocol, that a root contention situation is solved in one atomic step that no device has the force root ag set to true, and that communication can be modelled with nite queues. Since our aim is to show that whenever timers in the model expire, there is indeed a cycle in the network, and that the timers will expire in case of a cycle in the network, we are trying to show that the timers do not expire too soon or too late. In our proofs we use invariants that express worst case scenarios in terms of delay. So we are actually performing a worst case analysis on the timing proposed in IEEE 1394. In this way, we establish a relation between the parameters of the protocol in terms of minimal and maximal values. We expect that in a next re nement step it is possible to include the result from [27], to get closer to the IEEE 1394 behaviour without much e ort. The next re nement step could then be to add a force root ag to the model, thus expressing that devices behave a little di erent to increase their chances at leadership. In order to obtain a correctness statement about IEEE 1394 with all its detail, it still has to be shown that modelling the IEEE 1394 communication of voltages on wires by messages and nite queues is correct. We expect that in this situation, we will not just have a judgement on correctness, but we will also be able to say how the timing constants in IEEE 1394 could/should be adjusted. Our assumptions As a speci cation of the desired behaviour, we have taken the most detailed model TIP3 from [7]. In [7] it is shown that the behaviour of TIP3 meets the requirements for the tree identify phase. TIP3 is a very abstract model of the tree identify phase, in the sense that it abstracts from a lot of details. We introduce a model TIP4, which is more detailed than TIP3, and prove that it is a re nement of TIP3. In this way, the correctness of the behaviour of TIP4 can be derived from the correctness of the behaviour of TIP3. Our justi cation for still leaving out many implementation details that may a ect the correctness of the protocol, is that we intend to reuse as much as possible of the proofs already 6 established. This can only be done in a manageable way if we do not add too many details. As it is, the proofs for our veri cation are already quite lengthy and involved. See also Section 6 for a discussion of our results. The abstractions have been chosen as follows. In TIP3, it is assumed that the devices signal a cycle by merely checking the network topology. In TIP4, the devices use a timer, which conforms to IEEE 1394. In both TIP3 and TIP4, communication between devices is modelled by sending messages on queues. In a IEEE 1394 network, the devices communicate by asserting signals (de ned in terms of voltages) on wires for a certain time. In both TIP3 and TIP4, it is assumed that no device has the force root ag set to true. In both TIP3 and TIP4, the network is assumed to be connected and to be xed throughout the protocol. There may be cycles in the topology. In both TIP3 and TIP4, the root contention situation is solved in one atomic step, as opposed to the IEEE 1394 protocol which involves picking a random number, and which repeats until the symmetry is broken. Note that the root contention protocol has been formally speci ed and proved correct in [27]. In both TIP3 and TIP4, all devices enter the tree identify phase at the same time. In TIP3, no timing is used whatsoever. In TIP4, timing is used for determining whether the network topology contains a cycle (see above), and for determining the actual delivery time of messages. The IEEE 1394 delay between the moment of sending and reception and processing of a signal is caused by di erence in clocks of the devices, the length and propagation delay of the wires, and the di erence in the tree identify phase enter moment of the sending and receiving device. In TIP4, the delay of message is determined at the moment that the message is being received. This delay may vary between the bounds caused by di erence in clocks of the devices, and by the length and propagation delay of the wires. Although the second factor is constant, we have modelled the choice of delay to be completely free for each receive operation. Since we are after the bounds on the timing constants in relation to the network topology with respect to detecting cycles, we are establishing the property that the cycle detection timer will not expire too soon or too late. Therefore we are actually performing a worst case analysis. The worst case scenarios for IEEE 1394 and our model are the same, under the assumption that all devices enter the tree identify phase at the same moment. 3 IOA models We present two models in the IOA language [5] of the tree identify protocol, namely TIP3 and TIP4. The IOA model for TIP3 comes (almost) literally from [7] and gives an abstract and untimed model of the protocol behaviour. It has been shown in [7] that this model has the desired behaviour of electing exactly one device for root if there is no cycle in the network. If there is a cycle in the network, all devices that are part of this cycle will detect this and give an error message. 7 signature internal childrenknown(d: Dev), addchild(d:Dev, p:Port), receivemes(d:Dev, p:Port, m:Mes), solverootcontent(d:Dev, p:Port) output root(d:Dev), loopdetect(d:Dev) time Figure 6: Signature for TIP3 and TIP4. The IOA language The IOA language facilitates precise and readable descriptions of I/O automata [16, 17]. Since our models are timed, we have added a time action, according to the de nition in [19]. IOA contains the basic types Bool, Nat, Int and Real with their standard operators, In addition type constructors Array, Seq ( nite sequences) and Set ( nite sets) are part of the language. The notation [ ] is used for array subscripting, an array with a value e in all cells is denoted by const(e). The operation ` appends an element at the end of a sequence and the operations head and tail have the usual meaning. We assume the type Time which is the (prede ned) type Real restricted to nonnegative values. We assume the extra types Mes and Pack, and operations mhead, thead, avail and notime. The type Mes de nes the di erent message contents that may be exchanged between devices, and the type Pack records the contents and the time of sending of a message. Timed message queues are sequences of elements of the type Pack. The operations do the following: mhead gives the message part of the head of a timed message queue, thead gives the time part of the head of a timed message queue, avail checks whether the message in the head of a timed message queue is available with respect to the timing and has the required contents, and notime discards the timing information of each element in a timed message queue, thus turning it into an untimed message queue. The types and operations are de ned as follows: Type Mes enumeration of parent, ack Type Pack tuple of mes:Mes, time:Time mhead(q:Seq[Pack]) = head(q).mes thead(q:Seq[Pack]) = head(q).time avail(t:Time, q:Seq[Pack], m:Mes) = if q=fg then false else (t thead(q) + MinDelay) ^ (m = mhead(q)) notime(q:Seq[Pack]) = if q=fg then fg else mhead(q) ` notime(tail(q)) In Section 4 we give several de nitions and operations that concern network topologies. Given a network N = hD;P; dev; peeri, we assume the types Dev=D and Port=P and all operations as de ned in Section 4. The TIP models The signature part for both models is shown in Figure 6. The connected network N = hD;P; dev; peeri is a parameter for both models. In addition, the constants 8 MinDelay, MaxDelay, MinLpdtime, and MaxLpdtime are parameters for TIP4. We assume MinDelay MaxDelay and MinLpdtime MaxLpdtime. The IOA description of TIP3 is shown in Figure 7. The action de nitions are almost equal to those of TIP4, so we refer to the explanation below. The model TIP3 comes (almost) literally from [7]. The rst change is the addition of the time action, whose precondition is true, and whose e ect is empty. The second change is the use of the oncycleN predicate, which recognizes not just devices that are on a cycle, but also devices that are on a path between two cycles (see Section 4). Our veri cation shows that these devices also detect a cycle in the protocol and give an error message (see property I11 in De nition 5.3, Section 5.2). The IOA description of TIP4 is shown in Figure 8. The model TIP4 is a proper timed IOA model: there is a state variable time which is used as a global clock, and messages sent on queues now also contain the time at which they were sent, so the destination can check whether the message is already available at a certain moment. A message is available at least after MinDelay time units have passed or ultimately after MaxDelay time units have passed. The condition for detecting a cycle in the network also depends on time, and not (as in TIP3) on the predicate oncycleN which is based on the structure of the network. It is our goal to show that cycle detection will occur if and only if there really is a cycle present in the network. We now give a short explanation of each action of TIP4. Whether a device is in the initial phase is re ected in the state variable init. When init is true, only actions addchild and childrenknown can be enabled. With addchild a parent request may be received (if the operation avail indicates that the parent request is available) and the corresponding port is added to the collection of children. The action childrenknown marks the end of the init phase. It can only be performed when there is at most one port left which is not in child, and when it is performed, an acknowledgement is sent to all peer devices that are connected to a port in child and a parent request is sent to the peer device connected to the port that is not in child, if any. If a device is on a cycle, then it does not ever reach the state in which childrenknown is enabled, because two of its peer devices are also on a cycle. In this situation, the action loopdetect should be performed. In TIP3, the cycle is detected with the oncycle predicate. In TIP4, a timer signals that the device stays in the init phase too long, and therefore must be on a cycle. As soon as a device has left the init phase, it must wait for a message on the one remaining port that is not in child. If there is no such port, then the device is the root of the tree of parents and children, and can perform the root action. If there is such a port, then the action receivemes can be performed as soon as the message is available. The expected message is an acknowledgement, after which the contribution of the device to the leader election is over. If an unexpected parent request is received, then the device is in root contention with the peer device that sent the parent request. The peer device has received or will receive the parent request that was sent earlier, and thus has signalled or will signal the root contention. As soon as both devices have signalled root contention, the action solverootcontent can be performed to break the symmetry and add one of the two ports involved to child. The device whose port is added to child can then perform the root action. The time action signals the passing of time, by increasing the value of time. Time passage may not occur if there are other actions that cannot be delayed any further. Actions childrenknown and root are urgent, which means that they should happen at the rst moment when they are enabled. Actions addchild and receivemes are also urgent, but they are enabled only when a message becomes available. Since the message becomes available in the interval [t + MinDelay; t + MaxDelay] with t the time of sending, we require that time does not pass beyond the right-hand border of this interval. The action loopdetect depends on the the value of time and can happen anywhere in the interval 9 automaton TIP3 states child: Set[Port] := fg mq: Array[Port,Seq[Mes]] := const(fg) init: Array[Dev,Bool] := const(true) rc, root, lpd: Array[Dev,Bool] := const(false) transitions internal childrenknown(d) pre init[d] ^ size(ports(d)-child) 1 e init[d] := false; for p in ports(d) do if p 2 child then mq[p] := mq[p] ` ack else mq[p] := mq[p] ` parent od internal addchild(d,p) where d = dev(p) pre init[d] ^ head(mq[peer(p)]) = parent e child := insert(p, child); mq[peer(p)] := tail(mq[peer(p)]) internal receivemes(d,p,m) where d = dev(p) pre : init[d] ^ ports(d)-child = fpg ^ head(mq[peer(p)]) = m e if m = parent then rc[d] := true ; mq[peer(p)] := tail(mq[peer(p)]) internal solverootcontent(d,p) where d = dev(p) pre rc[d] ^ rc[dev(peer(p))] e child := insert(p,child); rc[d] := false; rc[dev(peer(p))] := false output root(d) pre : init[d] ^ : root[d] ^ ports(d) child e root[d] := true output loopdetect(d) pre oncycleN(d) ^ : lpd[d] e lpd[d] := true time where > 0 pre true e Figure 7: Automaton TIP3. 10 automaton TIP4 states child: Set[Port] := fg mq: Array[Port,Seq[Pack]] := const(fg) init: Array[Dev,Bool] := const(true) rc, root, lpd: Array[Dev,Bool] := const(false) time: Time := 0 transitions internal childrenknown(d) pre init[d] ^ size(ports(d)-child) 1 e init[d] := false; for p in ports(d) do if p 2 child then mq[p] := mq[p] ` [ack,time] else mq[p] := mq[p] ` [parent,time] od internal addchild(d,p) where d = dev(p) pre init[d] ^ avail(time,mq[peer(p)],parent) e child := insert(p, child); mq[peer(p)] := tail(mq[peer(p)]) internal receivemes(d,p,m) where d = dev(p) pre : init[d] ^ ports(d)-child = fpg ^ avail(time,mq[peer(p)],m) e if m = parent then rc[d] := true ; mq[peer(p)] := tail(mq[peer(p)]) internal solverootcontent(d,p) where d = dev(p) pre rc[d] ^ rc[dev(peer(p))] e child := insert(p,child); rc[d] := false; rc[dev(peer(p))] := false output root(d) pre : init[d] ^ : root[d] ^ ports(d) child e root[d] := true output loopdetect(d) pre MinLpdtime time MaxLpdtime ^ init[d] ^ : lpd[d] e lpd[d] := true time where > 0 pre 8 d,p: ^ : pre(childrenknown(d)) ^ : pre(root(d)) ^ if init[d] ^ : lpd[d] then time+ MaxLpdtime ^ if mq[p]6=fg then time+ thead(mq[p])+MaxDelay e time := time+ Figure 8: Automaton TIP4. 11 [MinLpdtime; MaxLpdtime], so we require that time does not pass beyond MaxLpdtime. The only action that is not mentioned in the precondition of the time action, is solverootcontent. The reason for this is that in the IEEE 1394 documentation, there is a small sub-protocol with timers that is used to break the symmetry, instead of the one action that represents this sub-protocol in TIP4. Since this sub-protocol is not guaranteed to end in nite time (due to randomly drawn numbers), we cannot say at what time the action solverootcontent will take place. Hence we have put not requirement on the time action for solverootcontent. The root contention solving protocol is discussed and proved correct in [27]. 4 Network preliminaries This section gives some de nitions and properties of network topologies which we will need in the veri cation. 4.1 Networks De nition 4.1 A network is a quintuple hD;P; dev; peeri, where D is a non-empty set of devices. P is a set of ports. dev : P ! D. peer : P ! P with for all p: peer(peer(p)) = p and p 6= peer(p). For d 2 D, we de ne the abbreviation ports(d) = fpjp 2 P ^ dev(p) = dg. For d 2 D, the predicate leafN (d) holds if size(ports(d)) = 1. The network consists of a collection of devices, each of which has a set of ports. Each port is connected to one other port with a cable, which is captured by the function peer. Each port has a connection and no port is connected to itself. The cable connection itself is referred to as a cable hop. Since for each p 2 P , dev(p) is de ned, it follows that P = [d2Dports(d). We will let variables p; p0; p00; p0; : : : range over ports, and d; d0; d0; : : : over devices. 4.2 Paths, cycles The following de nitions and lemmas are necessary to identify paths, cycles, etc. in the network. Throughout this section, we x a network N = hD;P; dev; peeri. De nition 4.2 A path in N is a possibly empty sequence of ports = p0p1 : : : pn, such that: if is not empty, then n is odd for all 0 i; j n: i 6= j ! pi 6= pj for all i 2 f1; 3; : : : ; ng: pi 1 = peer(pi) ^ (i < n! dev(pi+1) = dev(pi)). 12 We denote the rst and last port of with first( ) = p0 and last( ) = pn. We denote the length of with length( ) = (n + 1)=2. We denote the path obtained by reversing with reverse( ) = pn : : : p0. Path is a path from d1 to d2 in N if dev(first( )) = d1 and dev(last( )) = d2. We say that a device d is on i there is a port p in such that d = dev(p). We say that paths 1 and 2 overlap i there is a port p both in 1 and in 2. We denote the maximum length of the shortest path in N between any two devices by MaxHop(N) = max(fnjd1; d2 2 D ^ n = min(flength( )j is path from d1 to d2g)g). A basic cycle in N is a path = p0 : : : pn in N such that n > 0 and dev(p0) = dev(pn). A cycle path in N is a path = p0 : : : pi : : : pj : : : pn in N such that i < j, and p0 : : : pi and pj : : : pn are basic cycles. The predicate oncycleN (p) is true i there is a basic cycle or a cycle path in N such that p is on it. The predicate oncycleN (d) is true i there is a port p 2 ports(d), such that oncycleN (p) holds. A path re ects a walk through the network by concatenating cable hops, without visiting the same port (i.e. the same hop) twice. We will let ; 0; 0; : : : ; ; : : : ; ; : : : range over paths. The length of a path is the number of cable hops included in that path. The value MaxHop(N), which is an upper bound to the mininum number of cable hops between any two devices, will be used as a restriction of the networks on which the protocol is to operate. Ports that are part of a basic cycle remain inactive during the protocol, as we will show later. A cycle path can identify ports which are wedged between basic cycles without being part of such a cycle themselves. We will show that these ports also remain inactive during the protocol. Lemma 4.3 If = p0p1p2 : : : pn is a basic cycle in N , then p2 : : : pnp0p1 and reverse( ) are also basic cycles in N . If 1 2 3 is a basic cycle in N and 2 is a basic cycle in N , then 1 3 is a basic cycle in N . Lemma 4.4 oncycleN (p)! oncycleN (peer(p)) Lemma 4.5 oncycleN (p)! size(fpjp 2 ports(dev(p)) ^ oncycleN (p)g) 2 4.3 Connected networks, subnetworks The following de nitions and lemmas are necessary to identify subnetworks in a network. The types of subnetworks de ned here will be used in the protocol to quantify the worst-case time that it takes for a device to complete its part in the protocol. De nition 4.6 Let N = hD;P; dev; peeri and N 0 = hD0; P 0; dev0; peer0i be networks. N is connected if for each two devices d; d0 2 D there is a path from d to d0 in N . N 0 is a subnetwork of network N i D0 D, P 0 P , dev0 dev, and peer0 peer. N 0 is induced by D00 and N i D00 = D0 D P 0 = fpjp 2 P ^ dev(p) 2 D0 ^ dev(peer(p)) 2 D0g dev0 = f(p; d)jp 2 P 0 ^ d 2 D0 ^ dev(p) = dg peer0 = f(p; p0)jp; p0 2 P 0 ^ peer(p) = p0g13 The function Steps(N; d) is de ned by the following equation: Steps(N; d) = 0 if leafN (d) or oncycleN (d) 1 + Steps(N 0; d) otherwise where N 0 is induced by (D fdjd 2 D ^ leafN (d)g) and N The function Shrink is de ned by the following equation: Shrink(N;n0) = N if n0 = 0 Shrink(N 0; n0 1) otherwise where N 0 is induced by (D fdjd 2 D ^ leafN (d)g) and N The function Steps gives the one but greatest distance between a device and a leaf in the network. This number is determined by the number of steps it takes for such a device to become a leaf, when in each step all leafs are removed. For a device that is part of a cycle, the value of Steps has no meaning and will not be used. The function Shrink gives the remains of the original network after removing the leaf devices in the network in each of the indicated number of steps. The correspondence between Steps and Shrink is obvious: if Steps(N; d) = n then d is a leaf in Shrink(N;n). Notice that by de nition of `induced by', for each n: Shrink(N;n) is a subnetwork of N and if N is a connected network, then so is Shrink(N;n). Lemma 4.7 Let N = hD;P; dev; peeri be a connected network, and d1; d2 2 D. If oncycleN (d1), oncycleN (d2), and is a path from d1 to d2 in N , then for each p 2 : oncycleN (p) Proof (Sketch) Since oncycleN (d1), there must be a basic cycle or cycle path such that d1 is on it. Since oncycleN (d2), there must be a basic cycle or cycle path such that d2 is on it. In the full proof, we x and and show for each fragment 0 of which is not already part of or , that a basic cycle or cycle path can be constructed such that 0 is part of it. This is done with a case distinction on the structure of and . Lemma 4.8 Let N = hD;P; dev; peeri be a network, and d 2 D and :oncycleN (d). If Steps(N; d) = n then size(fp0jp0 2 ports(d) ^ (oncycleN (dev(peer(p0)) _ Steps(N; dev(peer(p0))) n)g) 1. Lemma 4.9 Let N = hD;P; dev; peeri be a connected network. Then for each d Steps(N; d) bMaxHop(N)=2c if 8d0 2 D : :oncycleN (d0) max(0; MaxHop(N) 1) otherwise Proof (Sketch) The full proof shows by contradiction that the constant m cannot be greater than the value proposed. The contradiction is obtained by induction on the longest path in the network. 5 Veri cation This section gives our formal veri cation proofs that show that our model of the IEEE 1394 tree identify protocol works correct. Section 5.1 gives some invariant properties of the model TIP3 that were proved in [7]. Section 5.2 gives some invariant properties of the model TIP4. Section 5.3 14 gives the proof that under certain timing restrictions the behaviour of TIP4 is included in the behaviour of TIP3, which allows us to use the results from [7] and conclude that the safety aspects of cycle detection and root election in TIP4 meet the IEEE 1394 requirements. The proof uses simulation techniques from [19] which are listed in Appendix A. The appendix also presents a new result for using invariants in stepwise re nement, which is useful for this paper because it allows us to reuse invariants properties from [7] without extra e ort. In Section 5.4 we prove some liveness properties for TIP4. Finally, in Section 5.5 we discuss whether the IEEE 1394 timing constants obey the restrictions that we found in Section 5.3. Throughout this section we x connected network N = hD;P; dev; peeri as the parameter for TIP4. We let s,t range over states of TIP4, ; 0 over Time, and m over Mes. 5.1 Invariants over TIP3 The following properties come from PVS code used to check the proofs for [7]. Lemma 5.1 The following properties are invariants for TIP3. For all s 2 reachable(TIP3): I 0 1(d) = init[d]! :rc[d] I 0 2(p) = init[dev(p)]! mq[p] = fg I 0 3(p) = init[dev(p)]! peer(p) 62 child I 0 4(d) = init[d] _ size(ports(d) child) 1 I 0 5(p) = length(mq[p]) 1 I 0 6(p) = p 2 child! mq[peer(p)] = fg I 0 7(p) = rc[dev(p)]! mq[peer(p)] = fg I 0 8(p) = head(mq[p]) = parent! p 62 child I 0 9(p) = rc[dev(p)]! peer(p) 62 child I 0 10(p) = _ init[dev(p)] _ head(mq[p]) = parent _ peer(p) 2 child _ rc[dev(peer(p))] _ p 2 child We let I 0 1 (I 0 2, : : :) abbreviate fs 2 states(TIP4)js j= 8d : I 0 1 (d)g (fs 2 states(TIP4)js j= 8p : I 0 2 (p)g, : : :). Even though the predicate oncycleN has a di erent meaning in [7], we can assume that these properties are invariant since the proofs do not involve this predicate. 15 5.2 Invariants over TIP4 We rst de ne two useful abbreviations. De nition 5.2 The predicates initpeer and availparent are de ned as follows: initpeer(d; s) = fp0jp0 2 ports(d) ^ s:init[dev(peer(p0))]g availparent(d; s) = fp0jp0 2 ports(d) ^ avail(s:time; s:mq[peer(p0)]; parent)g The following properties are necessary for the proofs in Section 5.3. De nition 5.3 I1(d) = rc[d]! :init[d] I2(p) = init[dev(p)]! mq[p] = fg ^ peer(p) 62 child I3(d) = :init[d]! size(ports(d) child) 1 I4(p) = p 2 child! mq[p] = fg _ 9 : mq[p] = fg ` [ack; ] I5(p) = p 2 child! :rc[dev(peer(p))] I6(p) = :init[dev(p)] ^ p 62 child ! _ peer(p) 2 child _ (rc[dev(peer(p))] ^ mq[p] = fg) _ 9 : mq[p] = fg ` [parent; ] I7(p) = rc[dev(p)] ^ p 62 child! mq[peer(p)] = fg I8(p) = p 2 child! mq[peer(p)] = fg I9(p) = mq[p] 6= fg ! thead(mq[p]) time I10(d) = ^ ^ :oncycleN (d) ^ time = Steps(N; d) MaxDelay ! ^ size(initpeer(d; s)) 1 ^ size((ports(d) child) availparent(d; s)) 1 ^ ^ :oncycleN (d) ^ time > Steps(N; d) MaxDelay ! ^ :init[d] ^ 8p02 ports(d) : ^ p0 62 child ^ mhead(mq[p0]) = parent ! thead(mq[p0]) Steps(N; d) MaxDelay I11(d) = ^ MinLpdtime > max(0; MaxHop(N) 1) MaxDelay ^ init[d] ^ :oncycleN (d) ! time < MinLpdtime I12(p) = oncycleN (p) ! ^ p 62 child ^ init[dev(p)] ^ size(ports(dev(p)) child) 2 16 I13(d) = oncycleN (p) ^ :lpd[d]! time MaxLpdtime We let I1 (I2, : : :) abbreviate fs 2 states(TIP4)js j= 8d : I1 (d)g (fs 2 states(TIP4)js j= 8p : I2 (p)g, : : :). Now we prove that under the assumption that some of the properties from De nition 5.3 hold in each reachable state for TIP4, it follows that others hold in each reachable state for TIP4 as well. In Section 5.3, the assumptions will be ful lled by the corresponding properties for TIP3. Lemma 5.4 1. I9 is invariant for TIP4. 2. I10 is inductive relative to (I1 \ I2 \ I3 \ I4 \ I6 \ I7 \ I8 \ I9) for TIP4. 3. I11 is inductive relative to (I1 \ I2 \ I3 \ I4 \ I6 \ I7 \ I8 \ I9 \ I10) for TIP4. 4. I12 is inductive relative to (I1 \ I2) for TIP4. 5. I13 is inductive relative to I12 for TIP4. Proof (Sketch) Almost all items have a very straightforward proof, except Item 2 which requires a rather complicated case distinction of almost 5 pages. 5.3 TIP4 implements TIP3 We use the properties established in Section 5.2 to obtain that TIP4 implements TIP3. As an implementation relation we take inclusion of admissible timed traces. In order to obtain the implementation relation, we construct a function that is to be proved a weak timed re nement from TIP4 to TIP3. Given the complicated relations between the invariants for TIP3 and the properties for TIP4, we have been forced to either prove the properties for TIP4 that depend on invariants for TIP3 anew, or to prove the invariance of the properties for TIP4and the weak re nement in one proof, or to come up with a more elegant solution. The latter approach has given rise to some new su cient conditions, which are presented in Appendix A. To avoid confusion, all state variables from TIP3 are subscripted with 3, and all state variables from TIP4 are subscripted with 4. Since the action signatures are equal, we do not use these subscript on the action names. De nition 5.5 The function ref from states of TIP4 to states of TIP3 is de ned by the following equations: ref(s):child3 = s:child4 ref(s):mq3 = notime(s:mq4) ref(s):init3 = s:init4 ref(s):rc3 = s:rc4 ref(s):root3 = s:root4 ref(s):lpd3 = s:lpd4 Here, the function notime turns a timed message queue into an untimed one by discarding all timing information (See Section 3). Lemma 5.6 Let s 2 states(TIP3). 17 1. ref(s) 2 I 0 1 implies s 2 I1. 2. ref(s) 2 (I 0 2 \ I 0 3) implies s 2 I2. 3. ref(s) 2 I 0 4 implies s 2 I3. 4. ref(s) 2 (I 0 5 \ I 0 8) implies s 2 I4. 5. ref(s) 2 I 0 9 implies s 2 I5. 6. ref(s) 2 (I 0 5 \ I 0 7 \ I 0 10) implies s 2 I6. 7. ref(s) 2 I 0 7 implies s 2 I7. 8. ref(s) 2 I 0 6 implies s 2 I8. Lemma 5.7 If MinLpdtime > max(0; MaxHop(N) 1) MaxDelay, then 1. s 2 Start(TIP4) implies ref(s) 2 Start(TIP3). 2. s a !TIP4 t, s 2 (I9\I10\I11\I12\I13) and ref(s) 2 (\I 0 1\I 0 2\I 0 3\I 0 4\I 0 5\I 0 6\I 0 7\I 0 8\I 0 9\I 0 10) implies ref(s) a !TIP3 ref(t). Proof (Sketch) The proof is a straightforward ful llment of the requirements. The only interesting case in the proof is when TIP4 performs a loopdetect action. Here the most complicated property, I13, is used. Corollary 5.8 If MinLpdtime > max(0; MaxHop(N) 1) MaxDelay, then I1, I2, I3, I4, I5, I6, I7, I8, I9, I10, I11, I12, and I13 are invariant for TIP4. Proof By Lemmas 5.1, 5.4, 5.6 and 5.7 we can use Lemma A.2. Corollary 5.9 If MinLpdtime > max(0; MaxHop(N) 1) MaxDelay, then the function ref is a weak timed re nement from TIP4 to TIP3 with respect to (I9 \ I10 \ I11 \ I12 \ I13) and (I 0 1 \ I 0 2 \ I 0 3 \ I 0 4 \ I 0 5 \ I 0 6 \ I 0 7 \ I 0 8 \ I 0 9 \ I 0 10) Proof By Lemmas 5.1, 5.4, 5.6 and 5.7 we can use Lemma A.2. The implementation relation now follows easily. Theorem 5.10 If MinLpdtime > max(0; MaxHop(N) 1) MaxDelay, then t-traces(TIP4) t-traces(TIP3). Proof Combine Corollary 5.9 with Theorem 6.14 from [19]. 5.4 Liveness results for TIP4 In this section we show some liveness results for model TIP4. This starts with showing that TIP4 has no time deadlocks. Then we can prove that when a cycle is present, it will be detected, and that otherwise a root will be elected. Notice that we cannot use results from TIP3, since notions as quiescence and fairness are not present at the timed level. First we need to de ne a measure on reachable states, to indicate the amount of discrete actions that must be performed before passing of time will be enabled again. 18 De nition 5.11 The function Measure gives a 5-tuple to each reachable state s from TIP4, as follows: Measure(s) = hC; I;R;M;Li where C = size(P s:child) I = size(fdjs:init[d]g) R = size(fdj:s:root[d]g) M = size(fpjs:mq[p] 6= fgg) L = size(fdj:s:lpd[d]g) The ordering is the lexicographic ordering on 5-tuples of naturals, based on the ordering < on naturals. Since < is well-founded, is also well-founded. Now we prove the properties that we need for deadlock freedom, namely that when no discrete action is enabled, then the passage of time is enabled, and that at every moment in time at most a nite amount of discrete activity can occur. Proposition 5.12 If MinLpdtime > max(0; MaxHop(N) 1) MaxDelay, then for each s 2 reachable(TIP4) the following holds: 1. s enables an action from ([d;p;mfchildrenknown(d); addchild(d; p); receivemes(d; p;m); solverootcontent(d; p); root(d); loopdetect(d)g) [ ([ >0f g) 2. if s a ! t and for all > 0 : a 6= , then Measure(t) Measure(s). Proof (Sketch) 1. It is shown by contradiction that if no discrete action is enabled in s, then time passage must be enabled. 2. This is done with a straightforward case distinction on transitions from s. Now we show that TIP4 cannot get into a time deadlock by its own discrete activity. A timed I/O automaton that has this property is called feasible. Proposition 5.13 If MinLpdtime > max(0; MaxHop(N) 1) MaxDelay, then TIP4 is feasible. Proof From Proposition 5.12 it follows that each reachable state enables either a discrete action, or a time-passage action, and that there is not in nite execution fragment s0a1s1 : : : of TIP4 in which s0 is reachable and 8i; j : si:time = sj:time. This implies that each nite execution can be extended to an admissible execution. We now show that whenever there is a cycle in the network, it is detected by the protocol. Proposition 5.14 Let MinLpdtime > max(0; MaxHop(N) 1) MaxDelay, and let be an admissible execution of TIP4. If oncycleN (d) then contains an occurrence of lpd(d). 19 constant value reference min cable length 0 no restriction speci ed max cable length 4.5 m Section 1.1, Page 1, 1394-1995 max cable hops 16 Section 1.1, Page 1, 1394-1995 propagation delay 5.05 ns/m Section 4.2.1.4.3, Page 74, 1394-1995 min CONFIG TIMEOUT 166.6 s Table 7-14, Page 89, 1394-1995 166.6 s Table 7-14, Page 89, P1394a max CONFIG TIMEOUT 166.9 s Table 7-14, Page 89, 1394-1995 166.9 s Table 7-14, Page 89, P1394a Table 1: IEEE 1394 timing constants Proof Since time proceeds in without bound, and since initially s:lpd[d] is false and since s:lpd[d] can only be made true by an occurrence of lpd(d), it su ces to show that for each reachable state s in TIP4, if s:time > MaxLpdtime, then s:lpd[d]. This follows easily from Invariant I13. Unfortunately, it is not possible to prove that if there is no cycle in the network, then within nite time a root will be elected. This is due to the unknown duration of the root contention solving sub-protocol. The following proposition shows that if no root contention occurs, then indeed a root is elected in nite time. Proposition 5.15 Let MinLpdtime > max(0; MaxHop(N) 1) MaxDelay, and let = s0a1s1 : : : be an admissible execution of TIP4. If 8d : :oncycleN (d) and 8i; d : :si:rc[d], then 9d such that contains an occurrence of root(d). Proof (Sketch) It is shown that in each reachable state where (bMaxHop(N)=2c+2) MaxDelay time has passed, either the root action has already occurred, or it must occur after nite discrete activity and before more time can pass. 5.5 Are the IEEE 1394 timing constants correct? Table 1 gives the IEEE 1394 timing constants, and a reference to where they are to be found in the documentation. Here, 1394-1995 refers to [10] and P1394a refers to [11]. Note that the constants are the same for 1394-1995 and P1394a. From these numbers, we get the constants used for the formal veri cation as follows: MinDelay = min cable length propagation delay = 0ns MaxDelay = max cable length propagation delay = 22:72ns MinLpdtime = min CONFIG TIMEOUT = 166:6 s MaxLpdtime = max CONFIG TIMEOUT = 166:9 s MaxHop(N) max cable hops = 16 The question is then, do these constants meet the requirement for correct implementation? We found in Theorem 5.10 that the model behaves correctly if MinLpdtime > max(0; MaxHop(N) 1) MaxDelay. Since (16 1) 22:72 ns = 340:80 ns < 166:9 s, the answer is yes. If the devices in 20 IEEE 1394 enter the tree identify phase at the same time, if there is no device with the force rootag set to true, and if our model of the IEEE 1394 communication is correct, then we can saythe following with certainty: If a loop is in the network, it is detected, and that if there is noloop in the network, no loop will be detected and a root will be chosen.6 ConclusionsThe veri cation shows that under the assumptions made, the IEEE 1394 de nition of the treeidentify phase meets the requirements. Exactly one root is chosen when there is no cycle present,and a cycle is detected if and only if there is a cycle present in the network. It is obvious fromthe proofs that the re nement step from an untimed model to a timed model in combinationwith the desired property of correct cycle detection is a complicated one. More proofs aboutnetwork topologies are needed to make a quantitative analysis of the worst case scenarios. Alsothe invariant properties that are speci c to the model TIP4 become more complicated. Thee ort invested in the construction of these proofs adds up to about two months. We hope thatin further re nement steps these proofs can be reused with little e ort.As to the remaining IEEE 1394 details that we have not considered, we believe that theaddition of the delay in entering the tree identify phase will not a ect the correctness of theprotocol. Also the addition of the root contention solving protocol with its veri cation from[27] will probably not touch the critical behaviour parts of the root election or cycle detection.However, the correctness of a model obtained by adding the force root ag and the assumptionthat the message queues model the IEEE 1394 signal communication is not that obvious. Anextension of this work may show that either IEEE 1394 timing bounds can be tightened orshould be loosened.The advantage of the layered veri cation in this case is that we do not need to prove anythingabout the safety properties of root election, since our re nement proof give us safety immediately.Establishing the re nement was not as easy as expected, because of the complicated reuseof invariants at the abstract level. The extra lemma that was needed shows that the proofobligations can still be divided over small, clear proof steps.Establishing the desired liveness properties that express that indeed a cycle is detected whenthere is a cycle in the network topology and indeed a root is elected otherwise, do not followfrom the `implements' relation, since we have only proved inclusion of admissible traces. In anuntimed veri cation, liveness properties are proved by showing a fair trace inclusion, that is,each fair trace from the more detailed model is also a fair trace in the more abstract model.In most cases, the liveness property holds trivially for any fair trace of the abstract model,and therefore also for any fair trace of the detailed model. In a timed veri cation, liveness isoften expressed in terms of timing bounds. Then again the (admissible) trace inclusion yieldscorrectness. In our case, both of these methods do not work. We are comparing a timed modelto an essentialy untimed model and hence have no fairness that carries over from the moreabstract level to the (timed) detailed level. On the other hand, we have no timing requirementfor when the root should be elected. So we have had to prove the liveness completely on the levelof model TIP4, without reusing proofs from the level of TIP3. In most cases and especially intimed veri cations, proving safety involves many properties from which the greater part of theproof obligations for the liveness properties already follows. It can be argued from Section 5.4(four pages of hand-written proofs in the full version) that here the remaining proof obligation isnot trivial. Nevertheless, we consider model TIP4 to be highly complex, and expect that in other21 timed veri cations it will be easier to show that once time has proceeded beyond a certain point,the safety properties combined with the feasibility proofs give the desired liveness properties.We conclude that for proving safety and liveness properties in a situation with only untimedmodels or with only timed models, a layered veri cation is a very suitable proof method whichallows one to `divide and conquer' the proof obligations. In a situation where timed and untimedbehaviour are compared, we think that other methods should be used in addition, or the degreeof re nement should be very low in order for a layered veri cation to diminish the amount ofwork to be done in each layer. It would be very beni cial if the proofs constructed for this paperwere checked with a proof checker. Careful manual inspection can never replace the con denceobtained by such automated inspection. Some results have been obtained in checking invariantproofs for I/O automata, both timed and untimed, as can be seen in [2], and several papers whichare under construction [1]. We expect that such an e ort will be considerable, but manageable.Acknowledgements The following people have contributed to this paper. David Gri oenwas my partner in nding the essence of the TIP behaviour in the IEEE standard. Besides beingthe co-author of [4, 7], he also came up with an good version of model TIP4. Rudi Bloks explainedsome details of the IEEE standard which were vital for getting the models right. At the pointwhere I got stuck in an early veri cation attempt of this protocol, Frits Vaandrager suggestedand initiated the layered veri cation, and later he came up with the su cient conditions for theweak timed re nement. Finally, the anonymous referees have given many helpful comments.References[1] M. Archer. Personal communication, March 1999.[2] M. Archer and C. Heitmeyer. Mechanical veri cation of timed automata: A case study. In Pro-ceedings 1996 IEEEE Real-Time Technology and Applications Symposium (RTAS'96). IEEE Com-puter Society Press, 1996. A full version is available as Report NRL/MR/5540{98-8180 from URLhttp://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/1998/index1998.html.[3] J.W. Davies and S.A. Schneider. A brief history of timed csp. Theoretical Computer Science,138(2):243{271, 1995.[4] M.C.A. Devillers, W.O.D. Gri oen, J.M.T Romijn, and F.W. Vaandrager. Veri cation of a leaderelection protocol | formal methods applied to IEEE 1394. Technical Report CSI-R9728, ComputingScience Institute, University of Nijmegen, December 1997. Submitted.[5] S.J. Garland, N.A. Lynch, and M. Vaziri. IOA: A language for speci ying, pro-gramming, and validating distributed systems, December 1997. Available through URLhttp://larch.lcs.mit.edu:8001/~garland/ioaLanguage.html.[6] R. Gawlick, R. Segala, J.F. S gaard-Andersen, and N.A. Lynch. Liveness in timed and untimedsystems. In S. Abiteboul and E. Shamir, editors, Proceedings 21th ICALP, Jerusalem, volume 820 ofLecture Notes in Computer Science. Springer-Verlag, 1994. A full version appears as MIT TechnicalReport number MIT/LCS/TR-587.[7] W.O.D. Gri oen and F.W. Vaandrager. Normed simulations. In Proceedings CAV'98, volume 1427of Lecture Notes in Computer Science, pages 332{344. Springer-Verlag, 1998.[8] J.F. Groote and A. Ponse. The syntax and semantics of CRL. In A. Ponse, C. Verhoef, andS.F.M. van Vlijmen, editors, Algebra of Communicating Processes '94, Workshops in Computing.Springer-Verlag, 1995.22 [9] J.F. Groote and J.S. Springintveld. Focus points and convergent process operators | a proof strategyfor protocol veri cation. Technical Report 142, Logic Group Preprint Series, Utrecht University,1995. This report also appeared as Technical Report CS-R9566, CWI, 1995.[10] IEEE Computer Society. IEEE Standard for a High Performance Serial Bus. Std 1394-1995, August1996.[11] IEEE Computer Society. Draft Standard for a High Performance Serial Bus (Supplement). P1394aDraft 2.0, March 1998.[12] L. Kuhne, J. Hooman, and W.P. de Roever. Towards mechanical veri cation of parts of the IEEEP1394 serial bus. In I. Lovrek, editor, Proceedings 2nd International Workshop on Applied FormalMethods in System Design, Zagreb, pages 73{85, 1997.[13] Leslie Lamport. How to write a long formula. Formal Aspects of Computing, 6:580{584, 1994. Alsoappeared as SRC Research Report 119.[14] S.P. Luttik. Description and formal speci cation of the Link layer of P1394. In I. Lovrek, edi-tor, Proceedings of the 2nd International Workshop on Applied Formal Methods in System Design,Zagreb, pages 43{56, 1997. Also available as Report SEN-R9706, CWI, Amsterdam. See URLhttp://www.cwi.nl/~luttik/.[15] N.A. Lynch. Distributed Algorithms. Morgan Kaufmann Publishers, Inc., San Fransisco, California,1996.[16] N.A. Lynch and M.R. Tuttle. Hierarchical correctness proofs for distributed algorithms. In Proceed-ings of the 6th Annual ACM Symposium on Principles of Distributed Computing, pages 137{151,1987. A full version is available as MIT Technical Report MIT/LCS/TR-387.[17] N.A. Lynch and M.R. Tuttle. An introduction to input/output automata. CWI Quarterly, 2(3):219{246, September 1989.[18] N.A. Lynch and F.W. Vaandrager. Forward and backward simulations, I: Untimed systems. Infor-mation and Computation, 121(2):214{233, September 1995.[19] N.A. Lynch and F.W. Vaandrager. Forward and backward simulations, II: Timing-based systems.Information and Computation, 128(1):1{25, July 1996.[20] Z. Manna and A. Pnueli. Verifying hybrid systems. In R.L. Grossman, A. Nerode, A.P. Ravn, andH. Rischel, editors, Hybrid Systems, volume 736 of Lecture Notes in Computer Science, pages 4{35.Springer-Verlag, 1993.[21] Z. Manna and A. Pnueli. Temporal Veri cation of Reactive Systems: Safety. Springer-Verlag, 1995.[22] S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal veri cation for fault-tolerant architec-tures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107{125, February 1995.[23] S.A. Schneider. Timewise re nement for communicating processes. Science of Computer Program-ming, 28(1):43{90, 1997.[24] R. Segala. Modeling and Veri cation of Randomized Distributed Real-Time Systems. PhD thesis,Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology,June 1995. Available as Technical Report MIT/LCS/TR-676.[25] R. Segala and N.A. Lynch. Probabilistic simulations for probabilistic processes. Nordic Journal ofComputing, 2(2):250{273, 1995.[26] C. Shankland and M. van der Zwaag. The tree identify protocol of IEEE 1394 in CRL. ReportSEN-R9831, CWI, Amsterdam, November 1998. To appear in Formal Aspects of Computing.[27] M.I.A. Stoelinga and F.W. Vaandrager. Root contention in IEEE 1394. In Proceedings 5th Int.AMAST Workshop on Real-Time and Probabilistic Systems (ARTS'99). Springer-Verlag, 1999. Toappear.23 A Safe and Timed I/O AutomataWe review some basic de nitions from [6, 21, 19], and we give su cient conditions for includinginvariants in re nement proofs when the invariants at the re ned level depend on invariants atthe abstract level. These conditions are presented in Lemma A.2. Lemma A.4 is the timedversion, which is used in the veri cation in this paper.A.1 Safe I/O automataA safe I/O automaton B consists of the following components:A set states(B) of states (possibly in nite).A nonempty set start(B) states(B) of start states.A set acts(B) of actions, partitioned into three sets in(B), int(B) and out(B) of input ,internal and output actions, respectively.Actions in local(B) = out(B) [ int(B) are called locally controlled .A set steps(B) states(B) acts(B) states(B) of transitions, with the property thatfor every state s and input action a 2 in(B) there is a transition (s; a; s0) 2 steps(B).We let s; s0,.. range over states, and a,.. over actions. We write s a!B s0, or just s a! s0 if B isclear from the context, as a shorthand for (s; a; s0) 2 steps(B).Enabling of actions An action a of a safe I/O automaton B is enabled in a state s i s a! s0for some s0. Since every input action is enabled in every state, safe I/O automata are said tobe input enabled. The intuition behind the input-enabling condition is that input actions areunder control of the environment and that the system that is modeled by a safe I/O automatoncannot prevent the environment from doing these actions.Executions An execution fragment of a safe I/O automaton B is a nite or in nite alternatingsequence s0a1s1a2s2 of states and actions of B, beginning with a state, and if it is nite alsoending with a state, such that for all i, si ai+1! si+1. An execution is an execution fragment thatbegins with a start state. We write execs (B) for the set of nite executions of B, and execs(B)for the set of all executions of B. A state s of B is reachable if it is the last state of some niteexecution of B. We write rstates(B) for the set of reachable states of B.Traces Suppose = s0a1s1a2s2 is an execution fragment of B. Let = a1a2 . Then thetrace of is the sequence ( din(B) [ out(B)), denoted by ̂. With traces(B) we denote the setof traces of executions of B. For s; s0 states of B and a nite sequence of input and outputactions of B, we de ne s )B s0 i B has a nite execution fragment with rst state s, last states0 and trace .Invariants Let P;Q states(B). P is invariant for B if it is a superset of the reachable statesof B, i.e. rstates(B) P . P is inductive relative to Q if start(B) P and if for each s0 2 P \Q:s0 a!B s implies s 2 P .24 Re nements Let A and B be safe I/O automata. A re nement from A to B is a functionr : states(A) ! states(B) that satis es:1. If s 2 start(A) then r(s) 2 start(B).2. If s0 a!A s then r(s0) )B r(s), where = â.Let A and B be safe I/O automata with invariants P and Q, respectively. A weak re nementfrom A to B, with respect to P and Q, is a function r : states(A) ! states(B) that satis es:1. If s 2 start(A) then r(s) 2 start(B).2. If s0 a!A s, s0 2 P , and r(s0) 2 Q, then r(s0) )B r(s), where = â.Theorem A.1 Let A and B be safe I/O automata. If there exists a (weak) re nement from Ato B, then traces(A) traces(B).Using abstract and re ned invariants in a re nement Let A;B be safe I/O automata.The following lemma gives su cient conditions for a weak re nement from A to B when onewants to use P1; P2; Q such that Q is invariant for B, P1 is invariant for A depending on Q andthe de nition of the re nement function, and P2 is invariant for A depending on P1.Lemma A.2 Let A;B be safe I/O automata. Let Q be invariant for B and P2 be inductiverelative to P1 for A. Let r : states(A) ! states(B) such that1. r(s) 2 Q implies s 2 P1,2. s 2 start(A) implies r(s) 2 start(B), and3. s0 2 P2, r(s0) 2 Q and s0 a!A s implies r(s0) )B r(s), where = â.Then1. P1; P2 are invariant for A.2. r is a weak timed re nement from A to B with respect to P2 and Q.Proof1. By induction.IH(n) = 8s; : (s 2 rstates(A) ^ 2 execs(A) ^ = s0a1 s1 : : : sn ^ s = sn)! (r(s) 2 rstates(B) ^ s 2 (P1 \ P2 ))Base step: n = 0.By de nition of , s 2 start(A). By de nition of r, r(s) 2 start(B) so certainlyr(s) 2 rstates(B). Since Q is invariant for B, r(s) 2 Q. By de nition of r, s 2 P1.Since s 2 start(A), and since P2 is inductive relative to P1 for A, s 2 P2.Induction step: 8n n0 : IH(n).Let s 2 rstates(A) ^ 2 execs(A) ^ = s0 a1 s1 : : :sn0an0+1 sn0+1 ^ s =sn0+1 . Sinces0a1s1 : : :sn0 2 execs(A), certainlysn0 2 rstates(A). Combining this with n0 n0,we get IH(n0). Since IH(n0), r(sn0) 2 rstates(B) ^sn0 2 (P1 \ P2 ). Sincer(sn0) 2rstates(B) and Q is invariant for B,r(sn0) 2 Q. Sincesn0 an0+1! Asn0+1 and by25 de nition of r,r(sn0) )Br(sn0+1) with = [an0+1, hencer(sn0+1) 2 rstates(B),hencer(sn0+1) 2 Q. By de nition of r,sn0+1 2 P1. Sincesn0 2 (P1 \ P2) andsn0 an0+1! Asn0+1 and since P2 is inductive relative to P1 for A,sn0+1 2 P2.2. By Item 1, the assumption that Q is invariant for B and by de nition of r.A.2 Timed I/O automataA timed I/O automaton A is a safe I/O automaton whose set of actions includes R+, the setof positive reals. Actions from R+ are referred to as time-passage actions. Other actions arereferred to as discrete actions. Performing one or more consecutive time-passage actions is calledidling. We let d; d0; : : : range over R+ and, more generally, t; t0; : : : over the set R of real numbers.The set of visible actions is de ned by vis(A) = (in(A) [ out(A)) R+.We assume that a timed I/O automaton satis es the following axioms.S1 If s0 d! s00 and s00 d0! s, then s0 d+d0! s.For the second axiom, an auxiliary de nition is needed. A trajectory for a step s0 d! s is afunction w : [0; d] ! states(A) such that w(0) = s0, w(d) = s, andw(t) t0 t! w(t0) for all t; t0 2 [0; d] with t < t0:Now we can state the second axiom.S2 Each step s d! s0 has a trajectory.Axiom S1 gives a natural property of time, namely that if time can pass in two steps, then itcan also pass in a single step. The trajectory axiom S2 is a kind of converse to S1; it says thatany time-passage step can be \ lled in" with states for each intervening time, in a \consistent"way. Executions of timed I/O automata correspond to what are called sampling computationsin [20].Timed Traces The full externally visible behaviour of a timed I/O automaton can be inferredfrom its executions as follows: suppose = s0a1s1a2s2 is an execution fragment of a timedI/O automaton A. For each index j, let tj be given byt0 = 0;tj+1 = if aj+1 2 R+ then tj + aj+1 else tj:The limit time of , notation :ltime , is the smallest element of R 0 [f1g larger than or equalto all the tj . We say is admissible if :ltime = 1, and Zeno if it is an in nite sequence butwith a nite limit time. The timed trace t-trace( ) associated with is de ned byt-trace( ) = (((a1; t1)(a2; t2) )d(vis(A) R 0 ); :ltime):Thus, t-trace( ) records the visible actions of paired with their times of occurrence, as well asthe limit time of the execution. A pair is a timed trace of A if it is the timed trace of some niteor admissible execution of A. Thus, we explicitly exclude the timed traces that originate fromZeno executions. We write t-traces(A) for the set of all timed traces of A, t-traces (A) for theset of nite timed traces (the timed traces derived from the nite executions), and t-traces1(A)for the set of admissible traces (the timed traces derived from the admissible executions).26 Moves We say s0 p;A s is a t-move of A if A has a nite timed execution fragment =s0a1s1 : : : sn such that s0 = s0, s = sn and p = t-trace( ).Feasibility Let A be a timed I/O automaton. We say A is feasible if each element oft-traces (A) is the pre x of some element of t-traces1(A).Implementation relation LetA andB be timed I/O automata. A implements B if t-traces(A)t-traces(B).Re nements Let A and B be timed I/O automata. A timed re nement from A to B is afunction r : states(A) ! states(B) that satis es:1. If s 2 start(A) then r(s) 2 start(B).2. If s0 a!A s then r(s0) p;B r(s), where p = t-trace(s0as).Let A and B be timed I/O automata with invariants P and Q, respectively. A weak timedre nement from A to B, with respect to P and Q, is a function r : states(A) ! states(B) thatsatis es:1. If s 2 start(A) then r(s) 2 start(B).2. If s0 a!A s, s0 2 P , and r(s0) 2 Q, then r(s0) p;B r(s), where p = t-trace(s0as).Theorem A.3 Let A and B be timed I/O automata. If there exists a (weak) timed re nementfrom A to B, then t-traces(A) t-traces(B).Using abstract and re ned invariants in a timed re nement We now present the timedversion of Lemma A.2, since the timed version is used in the veri cation in this paper.Lemma A.4 Let A;B be timed I/O automata. Let Q be invariant for B and P2 be inductiverelative to P1 for A. Let r : states(A) ! states(B) such that1. r(s) 2 Q implies s 2 P1,2. s 2 start(A) implies r(s) 2 start(B), and3. s0 2 P2, r(s0) 2 Q and s0 a!A s implies r(s0) p;B r(s), where p = t-trace(s0as).Then1. P1; P2 are invariant for A.2. r is a weak timed re nement from A to B with respect to P2 and Q.Proof Similar to the proof for Lemma A.2.27